apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/mv/MvProductRankWeeklyEntity.java-27-52 (1)

27-52: ⚠️ Potential issue | 🟡 Minor

@Setter 전면 공개와 updatedAt 수동 관리에 대한 우려다.

운영 관점에서 다음 두 가지가 문제 소지가 있다:

1. 클래스 레벨 @Setter는 발행(publish) 이외 경로에서도 MV 레코드 필드를 임의 변경할 수 있게 한다. MV는 배치가 원자적으로 교체하는 읽기 전용 스냅샷 성격이므로, 외부에서 setVersion/setRankValue 등을 호출할 여지를 남기면 "요청 내 버전 고정" 불변식이 깨질 수 있다. 생성자(또는 정적 팩토리) 기반 구축 후 불변으로 유지하고, 필요한 세터만 선택적으로 노출하는 방식이 안전하다.
2. updatedAt은 nullable=false인데 JPA 라이프사이클 콜백(@PrePersist/@PreUpdate)이나 감사(auditing)가 없다. 호출부가 한 곳이라도 누락 시 저장 실패가 런타임에 발생한다. @PrePersist로 Instant.now() 기본값을 보장하고, publish 경로가 명시적으로 세팅할 때만 덮어쓰도록 하는 방어 장치가 필요하다.

제안 수정안

 `@Getter`
-@Setter
 `@NoArgsConstructor`(access = PROTECTED)
 public class MvProductRankWeeklyEntity {
@@
     `@Column`(name = "updated_at", nullable = false)
     private Instant updatedAt;
+
+    `@PrePersist`
+    `@PreUpdate`
+    void touchUpdatedAt() {
+        if (updatedAt == null) {
+            updatedAt = Instant.now();
+        }
+    }
 }

추가 테스트 제안: (a) updatedAt을 세팅하지 않고 저장해도 자동 채움되는지 확인, (b) (period_key, product_id) 유니크 제약 위반 시 예외 전파 검증(월간 엔티티도 동일 케이스 커버).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/mv/MvProductRankWeeklyEntity.java`
around lines 27 - 52, 클래스 레벨 `@Setter을` 제거하고 MvProductRankWeeklyEntity를 생성자(또는 정적
팩토리) 기반으로 불변화해 배치에서만 레코드를 생성하도록 수정하되, 꼭 필요한 경우(예: 발행 경로)만 제한적 접근의 세터를 남기십시오(예:
setVersion/setRankValue를 protected 또는 package-private로 변경 또는 제거). 또한 updatedAt
필드에 대해 JPA 콜백 메서드(`@PrePersist/`@PreUpdate)를 추가하여 persist/merge 시 null이면
Instant.now()로 자동 채워지게 하고, 퍼블리시 경로에서 명시적으로 덮어쓰는 경우만 허용하도록 방어하십시오; 대상 식별자는 클래스명
MvProductRankWeeklyEntity, 필드명 updatedAt, 메서드명 setVersion/setRankValue, 그리고 콜백
메서드(`@PrePersist/`@PreUpdate)입니다.

apps/commerce-batch/build.gradle.kts-12-13 (1)

12-13: ⚠️ Potential issue | 🟡 Minor

Flyway 중복 추적 및 마이그레이션 일관성을 검증하는 통합 테스트가 필요하다.

현재 구조에서는 commerce-api와 commerce-batch가 동일 locations: classpath:db/migration 경로를 사용하면서 V1__mv_product_rank_weekly_monthly.sql을 중복 정의하고 있다. 두 모듈은 각각 별도 history 테이블(flyway_schema_history_commerce_api, flyway_schema_history_commerce_batch)에서 마이그레이션을 추적하므로 직접 충돌은 피하지만, 다음 위험이 존재한다:

• 아키텍처 취약점: CREATE TABLE IF NOT EXISTS 패턴은 물리적 스키마 생성 중복을 방지하지만, 두 모듈이 독립적으로 V1을 기록하므로 마이그레이션 책임이 불명확하다. 배포 순서나 모듈 활성화 시점에 따라 히스토리 일관성이 깨질 수 있다.
• 테스트 부재: 현재 CommerceApiContextTest, CommerceBatchApplicationTest는 빈 로딩만 검증하며, 두 모듈을 순차 기동한 뒤 flyway_schema_history_*에서 중복 버전이나 실패 레코드가 없는지 확인하는 통합 테스트가 없다.

수정안:

• 통합 테스트에서 commerce-api → commerce-batch 순서로 기동하고 양쪽 history 테이블의 V1 레코드를 검증한다.
• 운영 배포 가이드에 Flyway 실행 책임(예: API-only 기동 시는 배치 Flyway 비활성)을 명시하거나, 마이그레이션 전담 모듈 분리를 검토한다.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/commerce-batch/build.gradle.kts` around lines 12 - 13, Add an
integration test that boots commerce-api then commerce-batch in sequence and
verifies Flyway histories to catch duplicate/failed migrations: write a test
(e.g., CommerceApiBatchFlywayIntegrationTest) that starts the commerce-api
context, then starts commerce-batch, and queries
flyway_schema_history_commerce_api and flyway_schema_history_commerce_batch to
assert there is exactly one V1__mv_product_rank_weekly_monthly.sql record per
history table and no failure entries; use the existing migration location
classpath:db/migration and the SQL name V1__mv_product_rank_weekly_monthly.sql
as identifiers, and fail the test if duplicate versions, failed rows, or
mismatched checksums are found—also add a note in deployment docs (or a test
flag) to demonstrate disabling batch Flyway when running API-only.

apps/commerce-batch/src/main/resources/db/migration/V2__mv_product_rank_staging.sql-2-14 (1)

2-14: ⚠️ Potential issue | 🟡 Minor

ENGINE/CHARSET/COLLATE 명시가 누락되어 V1과 불일치한다.

운영 관점에서 서버의 기본 스토리지 엔진/문자셋 설정에 따라 테이블 정의가 달라질 수 있다. V1(mv_product_rank_weekly/mv_product_rank_monthly)은 ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci를 명시하는 반면, V2 스테이징은 비어 있어 환경 간 재현성이 떨어지고 period_key/product_id JOIN·비교에서 collation 불일치 오류가 발생할 위험이 있다.

• 수정안: MV 테이블과 동일한 엔진/문자셋/콜레이션을 명시한다.
• 추가 테스트: MySQL 서버 기본값이 다른 환경(예: utf8mb3)에서의 마이그레이션 스모크 테스트를 Testcontainers로 검증한다.

♻️ 제안 수정안

     UNIQUE KEY uk_mv_rank_staging_period_product (period_type, period_key, product_id),
     KEY idx_mv_rank_staging_period_rank (period_type, period_key, `rank`)
-);
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-batch/src/main/resources/db/migration/V2__mv_product_rank_staging.sql`
around lines 2 - 14, The CREATE TABLE for mv_product_rank_staging in the V2
migration is missing explicit ENGINE/CHARSET/COLLATE settings, causing
environment-dependent differences and potential collation mismatches with
existing MV tables; update the CREATE TABLE statement for
mv_product_rank_staging to explicitly set ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
COLLATE=utf8mb4_unicode_ci (matching the V1 mv_product_rank_weekly/monthly
tables) so period_key/product_id comparisons and joins use the same
collation/engine across environments, and add a Testcontainers-based migration
smoke test to verify the migration on a MySQL instance with different defaults
(e.g., utf8mb3).

apps/commerce-api/src/test/java/com/loopers/application/ranking/RankingFacadeTest.java-72-112 (1)

72-112: ⚠️ Potential issue | 🟡 Minor

LGTM — MV 경로·상호배타 검증을 고르게 커버한다

loadMvPage 위임, dataSource="MV_WEEKLY", mvPublishVersion, date와 period 동시 지정 금지, MV + rankingSnapshotId 금지 케이스까지 계약을 빠짐없이 검증한다. 다만 운영 관점에서 두 가지 경계가 빠져 있어 보강을 권한다.

1. period="MONTHLY" 위임 케이스가 없다. 주간만 테스트하면 RankingMvPeriod 분기 중 한쪽이 회귀되어도 통과한다. 월간 위임 테스트를 한 건 추가해 dataSource="MV_MONTHLY" 매핑까지 동일하게 보장해야 한다.
2. periodKey가 null/빈 문자열/형식 불일치일 때 CoreException(BAD_REQUEST)를 던지는지에 대한 음성 테스트가 없다. RankingMvPeriod.parse와 periodKey 검증이 각각 분리되어 있으므로 한쪽이 누락되어도 탐지되지 않는 위험이 있다.

추가 테스트 예시는 기존 getRankings_whenWeeklyMv_shouldDelegateLoadMvPage를 MONTHLY로 복제하고, 잘못된 periodKey에 대한 assertThatThrownBy를 추가하는 형태로 충분하다.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-api/src/test/java/com/loopers/application/ranking/RankingFacadeTest.java`
around lines 72 - 112, Add tests to cover the MONTHLY MV branch and
invalid/null/empty periodKey validation: duplicate the existing
getRankings_whenWeeklyMv_shouldDelegateLoadMvPage as
getRankings_whenMonthlyMv_shouldDelegateLoadMvPage, mock
rankingQueryService.loadMvPage(RankingMvPeriod.MONTHLY, "2026M04", 1, 20) and
assert dataSource() == "MV_MONTHLY" and mvPublishVersion; and add negative tests
calling rankingFacade.getRankings(null, "MONTHLY", null/""/"bad-format", 1, 20,
Optional.empty()) (or similar combos) that assertThrownBy returns CoreException
to ensure RankingMvPeriod.parse and periodKey validation are enforced.

apps/commerce-batch/src/test/java/com/loopers/batch/ranking/metrics/RankingBatchJobMetricsTest.java-11-22 (1)

11-22: ⚠️ Potential issue | 🟡 Minor

실패 경로·stale seconds 계산 검증이 빠졌다

운영 관점 문제: 본 PR이 새로 도입한 메트릭은 batch.rank.job.failure.count, batch.rank.snapshot.stale.seconds, batch.rank.job.last.success.epoch 세 가지이지만, 이 테스트는 오직 "성공 시 last.success/stale 게이지가 등록되는지" + "last.success.epoch > 0" 만 검증한다. 실패 카운터 증가와 stale.seconds가 "현재 시각 − last success" 의미로 올바르게 계산되는지는 커버되지 않아, 경보(alert) 연동 시점에 값이 0이거나 잘못된 단위로 나오는 회귀를 감지할 수 없다.

수정안·추가 테스트: (1) recordFailure(period) 호출 후 batch.rank.job.failure.count 카운터가 tag(period=WEEKLY)별로 1 증가하는지 검증한다. (2) Clock을 주입 가능하게 해 recordSuccess 이후 가상 시간 진행 시 batch.rank.snapshot.stale.seconds 게이지가 경과 초만큼 증가하는지 검증한다. 현재처럼 > 0 단일 단언만 두면 메트릭 의미가 바뀌어도 테스트가 통과한다.

🧪 추가 테스트 예시

+    `@Test`
+    `@DisplayName`("recordFailure 시 failure.count 카운터가 period 태그별로 증가한다")
+    void recordFailure_shouldIncrementCounter() {
+        SimpleMeterRegistry registry = new SimpleMeterRegistry();
+        RankingBatchJobMetrics metrics = new RankingBatchJobMetrics(registry);
+
+        metrics.recordFailure("WEEKLY");
+        metrics.recordFailure("WEEKLY");
+
+        assertThat(registry.find("batch.rank.job.failure.count")
+                .tag("period", "WEEKLY").counter().count()).isEqualTo(2.0);
+    }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-batch/src/test/java/com/loopers/batch/ranking/metrics/RankingBatchJobMetricsTest.java`
around lines 11 - 22, Add assertions and a controllable Clock to cover failure
counting and correct stale-seconds computation: update the test to call
RankingBatchJobMetrics.recordFailure("WEEKLY") and assert the
SimpleMeterRegistry counter "batch.rank.job.failure.count" with tag
period=WEEKLY has incremented by 1; refactor or construct RankingBatchJobMetrics
to accept a java.time.Clock (or expose a constructor that accepts one), call
recordSuccess("WEEKLY","2026W15"), advance a fixed Clock by a known duration,
then assert "batch.rank.snapshot.stale.seconds" gauge value increased roughly by
that duration (and still has the "batch.rank.job.last.success.epoch" gauge > 0).
Ensure you reference the RankingBatchJobMetrics constructor/field that accepts
Clock and the methods recordSuccess/recordFailure when making changes.

apps/commerce-batch/src/main/java/com/loopers/infrastructure/ranking/batch/MvProductRankStagingJpaRepository.java-9-9 (1)

9-9: ⚠️ Potential issue | 🟡 Minor

파생 deleteBy...는 SELECT 후 row-by-row DELETE로 수행되므로 벌크 DELETE로 최적화할 것

운영 관점 문제: Spring Data JPA의 파생 deleteByPeriodTypeAndPeriodKey는 대상 엔티티를 먼저 SELECT로 로딩한 뒤 각 엔티티에 대해 개별 DELETE 문을 발행한다. 현재 staging이 period_key당 수십 건 규모라 체감되지 않지만, 실패 재시도나 백필로 staging이 누적되면 cleanup 단계에서 SELECT + N회 DELETE로 인한 GC 및 성능 압박이 발생한다.

호출부 RankingStagingRepositoryImpl에는 이미 @Transactional이 적용되어 트랜잭션 경계 문제는 없으나, 삭제 로직 자체를 벌크 처리로 변경하는 것이 안전하다.

수정안: @Modifying(clearAutomatically = true, flushAutomatically = true) + JPQL로 단일 DELETE 문으로 처리한다.

♻️ 수정 제안

-import org.springframework.data.jpa.repository.JpaRepository;
+import org.springframework.data.jpa.repository.JpaRepository;
+import org.springframework.data.jpa.repository.Modifying;
+import org.springframework.data.jpa.repository.Query;
+import org.springframework.data.repository.query.Param;

-    void deleteByPeriodTypeAndPeriodKey(String periodType, String periodKey);
+    `@Modifying`(clearAutomatically = true, flushAutomatically = true)
+    `@Query`("delete from MvProductRankStagingEntity s "
+         + "where s.periodType = :periodType and s.periodKey = :periodKey")
+    int deleteByPeriodTypeAndPeriodKey(`@Param`("periodType") String periodType,
+                                       `@Param`("periodKey") String periodKey);

추가 테스트: (1) 같은 (periodType, periodKey)로 1k+ 행을 적재한 뒤 cleanup 호출 시 실행된 DELETE 문 개수가 1이 되는지 SQL 로그 기반 통합 테스트, (2) periodType만 같고 periodKey가 다른 행은 삭제되지 않는지 경계 테스트를 추가한다.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-batch/src/main/java/com/loopers/infrastructure/ranking/batch/MvProductRankStagingJpaRepository.java`
at line 9, Derived method deleteByPeriodTypeAndPeriodKey performs SELECT then
row-by-row DELETE causing N+1 deletes; replace it with a bulk JPQL delete by
adding a repository method annotated with `@Modifying`(clearAutomatically = true,
flushAutomatically = true) and a matching `@Query`("DELETE FROM
MvProductRankStaging m WHERE m.periodType = :periodType AND m.periodKey =
:periodKey") (keep parameter names the same), ensure the calling class
RankingStagingRepositoryImpl still runs inside a `@Transactional` boundary, and
add integration tests that load 1k+ rows and assert a single DELETE SQL is
emitted and that rows with the same periodType but different periodKey are not
removed.

apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/mv/MvProductRankMonthlyJpaRepository.java-10-17 (1)

10-17: ⚠️ Potential issue | 🟡 Minor

Javadoc이 월간 리포지토리와 일치하지 않는다. 복붙 오류로 보인다.

findMaxVersionByPeriodKey의 Javadoc이 "주간 랭킹 MV 최대 버전을 조회한다"로 작성되어 있으나 본 클래스는 월간 MV 리포지토리이고, 쿼리 엔티티도 MvProductRankMonthlyEntity다. 주간 리포지토리에서 복붙된 것으로 보인다. 운영 관점에서 문서 오염으로 인해 온콜 대응 시 즉시 혼선을 유발하고 장기적으로 데이터 조회 오류를 야기할 수 있으므로 수정이 필요하다.

제안 수정

-    /**
-     * 주간 랭킹 MV 최대 버전을 조회한다.
-     *
-     * `@param` periodKey 기간 키
-     * `@return` 주간 랭킹 MV 최대 버전
-     */
+    /**
+     * 월간 랭킹 MV 최대 버전을 조회한다.
+     *
+     * `@param` periodKey 기간 키
+     * `@return` 월간 랭킹 MV 최대 버전, 데이터 없으면 null
+     */

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/mv/MvProductRankMonthlyJpaRepository.java`
around lines 10 - 17, The Javadoc for findMaxVersionByPeriodKey incorrectly says
"주간" (weekly) due to copy-paste; update the comment to correctly describe that
this is the monthly MV repository (class MvProductRankMonthlyJpaRepository)
querying MvProductRankMonthlyEntity for the maximum version by periodKey. Edit
the Javadoc above the method findMaxVersionByPeriodKey to reference "월간 랭킹 MV 최대
버전을 조회한다" and ensure the `@param` and `@return` descriptions refer to monthly
period/metadata so documentation matches the query and class purpose.

apps/commerce-batch/src/test/java/com/loopers/domain/ranking/batch/RankingBatchJobParametersTest.java-9-53 (1)

9-53: ⚠️ Potential issue | 🟡 Minor

배치 작업 파라미터 검증 테스트의 경계값과 오류 케이스 추가가 필요하다.

배치 작업 파라미터는 운영 장애의 첫 방어선이므로 다음 케이스 추가를 권한다.

경계값 테스트:

• WEEKLY: 2026W00(범위 하한, 예상 실패), 2026W01, 2026W52, 2026W53(유효한 범위)
• MONTHLY: 202600(범위 하한, 예상 실패), 202601, 202612(유효한 범위)

포맷 오류 테스트:

• 올바르지 않은 포맷: 2026-W15, 2026W1, 2026/04
• 대소문자 오류: "weekly", "monthly" (현재는 "DAILY" 케이스만 테스트)

null 및 유효성 테스트:

• periodRaw == null
• periodKey == null

예외 메시지 검증:
현재 hasMessageContaining으로 검증하고 있으나, 추가로 민감정보가 포함되지 않았는지, 사용자가 이해할 수 있는 메시지인지 확인한다.

또한 반복되는 assertThatThrownBy 패턴이 많으므로 @ParameterizedTest로 재구성하면 테스트 가독성과 유지보수성이 향상된다.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-batch/src/test/java/com/loopers/domain/ranking/batch/RankingBatchJobParametersTest.java`
around lines 9 - 53, Add comprehensive boundary, format, case-sensitivity and
null tests to RankingBatchJobParametersTest for
RankingBatchJobParameters.validate: include WEEKLY boundary cases (e.g.,
"2026W00" expected fail, "2026W01", "2026W52"/"2026W53" expected pass/fail as
appropriate), MONTHLY boundary cases (e.g., "202600" fail, "202601", "202612"
pass), malformed formats ("2026-W15", "2026W1", "2026/04") and lower-case period
inputs ("weekly", "monthly") to ensure validation rejects/accepts correctly, and
null checks for both periodRaw and periodKey to assert IllegalArgumentException;
consolidate repetitive assertThatThrownBy/doesNotThrowAnyException into
`@ParameterizedTest` variants to improve readability and maintainability while
keeping assertions (including message content checks) for each case.

apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/mv/MvProductRankMonthlyJpaRepository.java-16-19 (1)

16-19: ⚠️ Potential issue | 🟡 Minor

두 질의 사이의 배치 publish 동시성 관련 통합 테스트를 추가한다.

현재 코드는 요청 스코프 내에서 버전을 한 번 고정하여 두 번의 왕복을 진행한다. PR 목표는 타당하나 운영 관점에서 다음을 요구한다.

1. 데이터베이스 기본 격리 수준(REPEATABLE_READ) 기준으로 MAX(version) 조회 시점에 새 버전이 publish 트랜잭션 중일 때 부분 가시성 문제가 없는지 확인하는 통합 테스트를 추가한다. 현재는 Mockito 기반 단위 테스트만 있다.

2. 반환형 Integer(nullable)의 데이터 없을 때 호출부 처리(빈 페이지 반환 여부)를 단위 테스트로 명시하면 규약이 명확해진다. 현재 RankingQueryServiceTest.loadMvPage_whenNoVersion_shouldReturnEmpty() 테스트가 존재하므로 유지한다.

3. Optional<Integer> 반환으로 JPA 저장소 시그니처를 개선하면 null-safety가 명확해진다. 도메인 계층(RankingMvReadRepository)에서는 이미 Optional<Integer>를 사용하고 있으므로, JPA 저장소도 직접 Optional<Integer>를 반환하도록 변경하면 호출부(RankingMvReadRepositoryImpl)의 Optional.ofNullable() 래핑이 불필요해진다. 파생 메서드 findByPeriodKeyAndVersionOrderByRankValueAsc는 version 원시타입이므로 사전 null 가드가 필수이다.

추가: Line 11의 주석은 "주간 랭킹 MV" → "월간 랭킹 MV"로 수정한다.

N+1이나 페치 조인 관점의 위험은 없는 단순 키-기반 조회이므로 문제없다.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-api/src/main/java/com/loopers/infrastructure/ranking/mv/MvProductRankMonthlyJpaRepository.java`
around lines 16 - 19, Change the JPA repository and tests: update
MvProductRankMonthlyJpaRepository.findMaxVersionByPeriodKey to return
Optional<Integer> (replace Integer) so callers don’t need Optional.ofNullable,
ensure callers like RankingMvReadRepositoryImpl remove the extra wrapping;
keep/adjust findByPeriodKeyAndVersionOrderByRankValueAsc so the version
parameter is non-null (change its type to Integer or add a null-guard before
calling) to avoid passing a primitive when no version exists; add an integration
test that simulates concurrent publish and reads under DB REPEATABLE_READ to
verify that querying MAX(version) during a publish transaction does not cause
partial visibility (use real DB transaction control rather than Mockito); and
fix the comment on line 11 from "주간 랭킹 MV" to "월간 랭킹 MV".

apps/commerce-batch/src/main/java/com/loopers/batch/ranking/RankingPeriodKey.java-29-36 (1)

29-36: ⚠️ Potential issue | 🟡 Minor

RankingPeriodKey.weekly()는 ISO 규칙에 맞으나, 설계상 포맷 불일치로 인한 잠재적 결함이 있다.

코드 리뷰 결과, RankingPeriodKey.weekly()의 yyyyMMdd 생성 로직은 ISO-8601 월요일 앵커 규칙을 올바르게 구현하고 있으며, 연말/연초 경계 케이스(2026-01-01 → 20251229) 및 요일 경계(일요일) 테스트가 이미 RankingPeriodKeyTest에 명시적으로 추가되어 있다.

다만 다음 문제가 존재한다:

1. 포맷 불일치: RankingPeriodKey.weekly()는 yyyyMMdd 형식("20260406")을 반환하지만, RankingBatchJobParameters의 검증 규칙은 yyyyWww 형식("2026W15")을 기대하며, 현재 이 클래스는 테스트 코드에서만 호출되고 배치 운영 코드에서는 미사용 상태다. 배치 Job 파라미터는 외부에서 yyyyWww/yyyyMM 형식으로 직접 주입되므로 현재 실행에는 영향을 주지 않으나, RankingPeriodKey의 생성 포맷이 검증 규칙과 불일치하면 향후 마이그레이션 시 실수 여지가 있다.

2. 레거시 코드 정리: RankingPeriodKey 클래스가 운영 코드에서 실제로 사용되지 않는다면, 혼동을 방지하기 위해 제거하거나 용도를 명확히 할 것을 권장한다.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-batch/src/main/java/com/loopers/batch/ranking/RankingPeriodKey.java`
around lines 29 - 36, RankingPeriodKey.weekly() currently computes the
ISO-Monday anchor correctly but returns a yyyyMMdd string, which mismatches the
validation/expectation in RankingBatchJobParameters (expects yyyyWww); update
weekly() to format the anchor into the ISO week format (week-based-year + 'W' +
two-digit week-of-week-based-year, e.g. "2026W15") using the Java
week-based-year/week-of-week-based-year fields (or a DateTimeFormatter pattern
that emits week-based-year and week number) so the output matches
RankingBatchJobParameters validation; alternatively, if RankingPeriodKey is not
used in production, either remove the class or clearly deprecate it and document
its intended format to avoid future confusion.

apps/commerce-batch/src/main/java/com/loopers/infrastructure/ranking/batch/MvProductRankStagingEntity.java-20-26 (1)

20-26: ⚠️ Potential issue | 🟡 Minor

Redis 락 TTL 설정이 배치 정상 실행 시간보다 충분한지 확인한다.

유니크 제약 (period_type, period_key, product_id)로 구성된 설계는 Redis 락으로 동시성을 직렬화하고 delete 후 save를 같은 transaction 내에서 실행하므로 충돌 위험이 낮다. 그러나 Redis 락 TTL이 4시간으로 설정되어 있으므로, Job이 abnormal 종료되어 락 해제(afterJob)가 미실행되면 4시간 동안 동일 period의 재실행이 불가능하다. 정상 배치 실행 시간이 4시간을 초과하지 않더라도, 락 만료 전 강제 개입이 필요한 장애 상황이 발생할 경우 대기 시간이 길어진다.

스테이징 정리 및 적재 흐름

배치 Step 순서: periodLockStep (4시간 TTL 획득) → stagingCleanupStep (delete) → aggregateStep (집계) → publishStep (publish) → afterJob (락 해제)

락 해제는 JobExecutionListener.afterJob에서만 ownerToken 검증을 통해 실행되므로, 타 노드의 강제 해제는 방지된다.

추가 테스트:

• 정상 배치 완료까지의 평균 실행 시간을 측정하고 4시간 TTL과의 margin을 문서화한다.
• Job 강제 종료 시나리오에서 락 자동 만료 대기 없이 조기 복구할 수 있는 관리자 개입 절차(Redis 수동 락 제거, 또는 TTL 재조정) 가이드를 제공한다.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-batch/src/main/java/com/loopers/infrastructure/ranking/batch/MvProductRankStagingEntity.java`
around lines 20 - 26, The Redis lock TTL (currently 4 hours) used by
periodLockStep may be too long relative to actual job runtimes and blocks
recovery if afterJob doesn't run; measure average and worst-case execution time
of the batch steps (periodLockStep → stagingCleanupStep → aggregateStep →
publishStep → afterJob), document the margin vs the 4-hour TTL, and then either
reduce the TTL or implement lock renewal/heartbeat in periodLockStep to extend
ownership while the job is running; additionally add an operational recovery
procedure that documents how to manually remove the Redis lock or adjust TTL
(including required checks of ownerToken in afterJob and safeguards to prevent
cross-node forced unlocks) so operators can safely recover from abnormal
termination without waiting the full TTL.

apps/commerce-batch/src/test/java/com/loopers/domain/ranking/batch/RankingStagingSnapshotValidatorTest.java-13-67 (1)

13-67: ⚠️ Potential issue | 🟡 Minor

경계·예외 케이스 보강 필요

운영 관점에서 staging 검증은 MV publish 직전의 최후 방어선이다. 현재 테스트는 정상 케이스 2개 + 실패 케이스 3개만 있어 다음 회귀를 놓칠 수 있다.

• size == 100 경계(정확히 100행)는 통과해야 한다는 명시적 검증이 없다. 향후 >와 >=가 뒤바뀌면 검출 불가.
• rank가 1이 아닌 값(예: 2, 5)에서 시작하는 경우의 "연속" 규칙 검증이 없다. 집계 쿼리가 ROW_NUMBER() 오프셋을 잘못 잡는 장애를 잡지 못한다.
• 입력이 null일 때의 계약(NPE vs 명시적 예외)이 정의/검증되지 않는다.
• product_id가 음수/0인 경우 정책(통과 여부)도 명시 테스트가 없다.

최소한 size==100 통과와 rank[0] != 1 실패 케이스 2개는 추가할 것을 권한다.

As per coding guidelines "단위 테스트는 경계값/실패 케이스/예외 흐름을 포함하는지 점검한다."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-batch/src/test/java/com/loopers/domain/ranking/batch/RankingStagingSnapshotValidatorTest.java`
around lines 13 - 67, Add unit tests to cover boundary and edge cases for
RankingStagingSnapshotValidator.validateOrThrow: add a test that builds exactly
100 rows (ranks 1..100) and asserts doesNotThrow, add tests that assert
validateOrThrow throws for snapshots whose first rank != 1 (e.g., starting at 2
and starting at 5) to catch ROW_NUMBER offset bugs, and add short tests to
define behavior for null input and product_id <= 0 (either expect NPE or a
specific IllegalArgumentException depending on current contract); reference the
test class RankingStagingSnapshotValidatorTest and the static method
validateOrThrow when adding these cases.

apps/commerce-batch/src/test/java/com/loopers/infrastructure/ranking/batch/RankingStagingRepositoryIntegrationTest.java-40-60 (1)

40-60: ⚠️ Potential issue | 🟡 Minor

"삭제 후" 시나리오가 실제로 삭제 동작을 검증하지 않는다

DisplayName은 "삭제 후 순위 행을 저장하면..."인데, 선행 seed 데이터가 없어 deleteByPeriodTypeAndPeriodKey 호출은 no-op과 구분되지 않는다. 운영 관점에서 배치 재실행 시 이전 staging 잔존 행이 깨끗이 제거되어야 publish가 올바른 스냅샷을 낸다. 현재 테스트로는 delete가 조용히 빠져도 통과한다.

수정안:

• save로 3~4행을 미리 저장 → delete 호출 → 전체 개수가 0이 되는지 확인 → 새 2행 저장 → 최종 2행과 기대 순서 검증.
• 추가로 서로 다른 periodKey(2026W15, 2026W16)를 같이 seed 후 2026W15만 delete하여 타 기간 행이 영향받지 않음(격리성)을 검증하는 테스트도 권한다. 배치의 멱등성과 기간 격리 계약은 운영 장애 시 데이터 복구 가능성과 직결된다.

As per coding guidelines "통합 테스트는 격리 수준, 플래키 가능성, 테스트 데이터 준비/정리 전략을 점검한다."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-batch/src/test/java/com/loopers/infrastructure/ranking/batch/RankingStagingRepositoryIntegrationTest.java`
around lines 40 - 60, Test currently calls deleteByPeriodTypeAndPeriodKey but
never seeds data, so the delete may be a no-op; update the test to first seed
3–4 rows via rankingStagingRepository.saveRankedRows for period "2026W15" (and
optionally additional rows for "2026W16"), then call
deleteByPeriodTypeAndPeriodKey("WEEKLY","2026W15") and assert
stagingJpaRepository.findByPeriodTypeAndPeriodKeyOrderByRankValueAsc("WEEKLY","2026W15")
returns empty, then save the two new rows with
rankingStagingRepository.saveRankedRows and finally assert size==2 and
ranks/order/productIds as before; also include an assertion that rows for
"2026W16" (if seeded) remain unchanged to verify period isolation.

apps/commerce-batch/src/test/java/com/loopers/infrastructure/ranking/batch/RankingStagingRepositoryIntegrationTest.java-62-81 (1)

62-81: ⚠️ Potential issue | 🟡 Minor

정렬 검증이 자명한 삽입 순서여서 회귀 탐지력이 약하다

현재 saveRankedRows에 넘기는 리스트 자체가 이미 rank 오름차순이라, 구현이 단순히 입력 순서를 그대로 반환해도 테스트가 통과한다. ORDER BY rank_value ASC의 실제 적용 여부를 검증하려면 입력을 내림차순(rank=2 먼저, rank=1 나중) 또는 무작위 순서로 넣고 반환이 오름차순인지 확인해야 한다. 또한 score 필드(BigDecimal) 반환값까지 같이 assert하면 DTO 매핑 누락 회귀도 잡을 수 있다.

📝 제안 diff

-                List.of(
-                        new RankingStagingRankRow(1, 10L, new BigDecimal("9.00")),
-                        new RankingStagingRankRow(2, 20L, new BigDecimal("1.00"))
-                )
+                List.of(
+                        new RankingStagingRankRow(2, 20L, new BigDecimal("1.00")),
+                        new RankingStagingRankRow(1, 10L, new BigDecimal("9.00"))
+                )
...
         assertThat(dtos.get(0).rank()).isEqualTo(1);
         assertThat(dtos.get(0).productId()).isEqualTo(10L);
+        assertThat(dtos.get(0).score()).isEqualByComparingTo("9.00");
         assertThat(dtos.get(1).rank()).isEqualTo(2);
+        assertThat(dtos.get(1).productId()).isEqualTo(20L);
+        assertThat(dtos.get(1).score()).isEqualByComparingTo("1.00");

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-batch/src/test/java/com/loopers/infrastructure/ranking/batch/RankingStagingRepositoryIntegrationTest.java`
around lines 62 - 81, The test currently inserts rows in ascending rank so it
can't detect missing ORDER BY; modify the
RankingStagingRepositoryIntegrationTest test method
findRankedRows_returnsOrderedDtos to call
rankingStagingRepository.saveRankedRows with a non-sorted input (e.g., rank 2
first then rank 1 or randomized order) using RankingStagingRankRow instances,
then call findRankedRows and assert the returned list is ordered by rank
ascending (check rank() sequence) and also assert the score BigDecimal values
(and productId()) on the returned DTOs to catch mapping/score regressions; keep
using saveRankedRows and findRankedRows method names and the
RankingStagingRankRow DTO in your assertions.

apps/commerce-api/src/test/java/com/loopers/domain/ranking/RankingQueryServiceTest.java-701-717 (1)

701-717: ⚠️ Potential issue | 🟡 Minor

TOP100 캡 테스트의 검증 범위가 부족하다

총합 캡(totalElements=100)만 검증하고 있어 운영 관점에서 다음 회귀를 놓친다.

• 101~105위 행이 실제로 응답에서 제외되는지(슬라이싱 경계),
• rows.size()가 요청 size=100과 캡의 교집합과 일치하는지,
• productRepository.findByIdInAndNotDeletedAsMap에 전달된 productId 집합이 TOP100으로 제한되었는지(상위 100개만 hydration 대상이 되어야 불필요한 DB 조회 부하가 없다).

현재 테스트는 productRepository가 빈 Map을 반환하므로 rows가 전부 누락되어도 통과한다. 캡 이후 실제 상위 100 행이 흘러가는지 ArgumentCaptor로 전달 인자 크기(<=100)를 검증하는 케이스를 추가하면 운영 시 과도한 IN 절·메모리 사용을 방지할 수 있다.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-api/src/test/java/com/loopers/domain/ranking/RankingQueryServiceTest.java`
around lines 701 - 717, The test loadMvPage_whenMoreThan100Rows_shouldCapTotal
only asserts totalElements; update it to also assert that the returned page
actually contains only the top-100 rows and that hydration is limited to those
IDs: after invoking rankingQueryService.loadMvPage(RankingMvPeriod.WEEKLY,
"2026W01", 1, 100) assert result.rows().size() == 100 and that the rows
correspond to the expected top-100 entries (i.e., exclude items 101–105), and
add an ArgumentCaptor for productRepository.findByIdInAndNotDeletedAsMap to
capture the passed productId collection and assert its size() <= 100 and that it
contains only the top-100 ids; this ensures slicing boundary correctness and
prevents unnecessary DB IN-queries.

apps/commerce-api/src/test/java/com/loopers/domain/ranking/RankingQueryServiceTest.java-656-682 (1)

656-682: ⚠️ Potential issue | 🟡 Minor

테스트 시나리오가 DisplayName을 충족하지 못한다

DisplayName은 "조회 중 더 높은 버전이 생겨도 요청 시작 시 고정한 버전만 사용한다"인데, mock은 findMaxVersionForWeekly("2026W30")에 대해 항상 Optional.of(1)만 반환하므로 "조회 도중 더 높은 버전이 publish되는" 상황이 전혀 재현되지 않는다. 운영 관점에서 배치 publish와 API 조회가 동시에 일어날 때의 요청 스코프 버전 고정이 핵심 계약인데, 현재 테스트는 단순히 "존재하지 않는 v=2 조회가 없음"만 검증할 뿐 레이스 상황의 안전성을 보장하지 못한다.

수정 방향:

• findMaxVersionForWeekly가 첫 호출 시 1, 두 번째 호출 시 2를 반환하도록 thenReturn(Optional.of(1)).thenReturn(Optional.of(2))로 설정한다.
• 이후 loadMvPage 결과의 mvPublishVersion이 1로 고정되고, findWeeklyByPeriodKeyAndVersionOrdered(..., 1)만 호출되는지 검증한다.
• 추가로 요청 스코프 내에서 findMaxVersionForWeekly가 단 1회만 호출되는지(verify(..., times(1)))도 같이 검증하여 재조회 시 최신 버전으로 바뀌는 회귀를 잡는다.

📝 제안 diff

-        when(rankingMvReadRepository.findMaxVersionForWeekly("2026W30")).thenReturn(Optional.of(1));
+        when(rankingMvReadRepository.findMaxVersionForWeekly("2026W30"))
+                .thenReturn(Optional.of(1))
+                .thenReturn(Optional.of(2));
...
+        verify(rankingMvReadRepository, times(1)).findMaxVersionForWeekly("2026W30");
         verify(rankingMvReadRepository, times(1)).findWeeklyByPeriodKeyAndVersionOrdered("2026W30", 1);
         verify(rankingMvReadRepository, never()).findWeeklyByPeriodKeyAndVersionOrdered("2026W30", 2);

As per coding guidelines "단위 테스트는 경계값/실패 케이스/예외 흐름을 포함하는지 점검한다."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-api/src/test/java/com/loopers/domain/ranking/RankingQueryServiceTest.java`
around lines 656 - 682, The test currently mocks
rankingMvReadRepository.findMaxVersionForWeekly("2026W30") to always return
Optional.of(1), so it doesn't simulate a higher version appearing during the
call; change the mock to thenReturn(Optional.of(1)).thenReturn(Optional.of(2))
so the first call returns 1 and a subsequent call would return 2, then assert
rankingQueryService.loadMvPage(...) returns mvPublishVersion() == 1 and verify
rankingMvReadRepository.findWeeklyByPeriodKeyAndVersionOrdered("2026W30", 1) is
called once and never with version 2, and also add
verify(rankingMvReadRepository, times(1)).findMaxVersionForWeekly("2026W30") to
ensure the service only reads the max version once (use the existing test’s
mocks and methods: findMaxVersionForWeekly,
findWeeklyByPeriodKeyAndVersionOrdered, loadMvPage, mvPublishVersion).

apps/commerce-batch/src/main/java/com/loopers/infrastructure/ranking/mv/MvProductRankWeeklyEntity.java-24-25 (1)

24-25: ⚠️ Potential issue | 🟡 Minor

Javadoc와 실제 구현이 일치하지 않는다(낙관적 락 미적용).

클래스 Javadoc(24-25줄)은 "@Version 필드로 동시 사용 시 커밋 단계에서 충돌 감지·롤백"을 명시하지만, version 필드에는 jakarta.persistence.Version 애노테이션이 없어 평범한 int 컬럼으로 취급된다. 결과적으로 JPA 낙관적 락은 동작하지 않으며, 동시 배치 publish 시 OptimisticLockException은 발생하지 않는다.

현재 publish 로직은 "replace" 전략(DELETE 후 INSERT)을 사용하므로 UPDATE 기반의 낙관적 락이 필요하지 않다. 따라서 오해를 유발하는 Javadoc을 제거하거나, 설계 변경 시 @Version 애노테이션을 추가해야 한다. ProductRankMvPublishRepositoryIntegrationTest는 replaceWeeklyPeriod/replaceMonthlyPeriod만 검증하며 OptimisticLockException 케이스가 없는 점도 이를 뒷받침한다.

운영 관점에서 문서와 실동작이 다르면 장애 회복 시 잘못된 가설로 디버깅이 지연된다. 다음 중 하나를 선택하여 처리하기를 권한다:

• Javadoc의 "@Version 필드로...롤백" 문구 제거
• 또는 향후 낙관적 락 적용 시 @Version 애노테이션 추가 및 관련 테스트 작성

MvProductRankMonthlyEntity(배치/API)와 MvProductRankStagingEntity도 동일한 패턴이므로 함께 정정하기를 권한다.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-batch/src/main/java/com/loopers/infrastructure/ranking/mv/MvProductRankWeeklyEntity.java`
around lines 24 - 25, The class Javadoc in MvProductRankWeeklyEntity claims
optimistic locking via a `@Version` field but the version field is a plain int
without jakarta.persistence.Version, so either remove the misleading Javadoc or
actually enable optimistic locking: add the `@Version` annotation to the version
field in MvProductRankWeeklyEntity (and mirror changes in
MvProductRankMonthlyEntity and MvProductRankStagingEntity) and update
ProductRankMvPublishRepositoryIntegrationTest to include an optimistic-locking
scenario; choose one approach and make the Javadoc and implementation consistent
(remove the "@Version ..." text if you keep the current DELETE-then-INSERT
replace strategy, or add `@Version` and tests if you want optimistic locking).

apps/commerce-api/src/main/java/com/loopers/domain/ranking/RankingMvRequestValidator.java-60-80 (1)

60-80: ⚠️ Potential issue | 🟡 Minor

ISO 주/월 입력 단계의 유효성 검증을 강화할 것을 검토한다.

WEEKLY_KEY 정규식과 범위 체크는 주차 01~53 범위만 허용하지만, 해당 연도가 실제로 53주를 갖는지는 검증하지 않는다. 예를 들어 2025W53은 존재하지 않는 ISO 주(2025년은 52주)이지만 현재 로직에서는 통과하며, 이후 조회 시 빈 결과를 반환한다. 배치 검증 규칙이 동일하므로, API 입력 단계에서 실제 유효한 주차를 검증하지 못하면 조회 장애 가능성이 있다.

또한 MONTHLY_KEY는 월 범위(01~12)만 검증하고 연도를 검증하지 않아, 000005처럼 비현실적 연도도 허용된다. 정책적으로 운영 범위(예: 2000~2099)를 지정해 검증할 것을 권한다.

수정 제안:

• java.time.Year.of(year).isLeap()과 java.time.YearMonth 또는 IsoFields.WEEK_OF_WEEK_BASED_YEAR를 사용해 실제 유효한 ISO 주(해당 연도의 주 수 범위)인지 검증한다.
• 월 검증에서 연도 범위(예: 1900~2100)도 함께 체크한다.

추가 테스트 제안: 2025W53(존재하지 않음) → BAD_REQUEST, 2026W53(존재) → 통과, 000001(연도 범위 외) → BAD_REQUEST를 경계값 테스트로 추가한다.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-api/src/main/java/com/loopers/domain/ranking/RankingMvRequestValidator.java`
around lines 60 - 80, validateWeeklyKey currently only checks format and 1-53
range; update validateWeeklyKey to parse the year (periodKey substring 0-4) and
compute the actual max ISO week for that year (e.g.,
LocalDate.of(year,12,28).get(IsoFields.WEEK_OF_WEEK_BASED_YEAR())) then reject
if the parsed week > maxWeek; keep using WEEKLY_KEY for format validation and
throw IllegalArgumentException on failure. For validateMonthlyKey parse the year
and month (substring 0-4 and 4-6), enforce a sensible year range (e.g.,
1900–2100) and use YearMonth.of(year, month) to validate the month/year
combination (throw IllegalArgumentException if out of range or invalid);
continue to use MONTHLY_KEY for initial format checks.

apps/commerce-batch/src/test/java/com/loopers/job/ranking/RankingBatchJobE2ETest.java-145-191 (1)

145-191: ⚠️ Potential issue | 🟡 Minor

동일 run.id 충돌로 인한 플래키 가능성이 있어 고유화가 필요하다.

두 호출 모두 addLong("run.id", System.currentTimeMillis())을 쓰는데, JobLauncherTestUtils는 RunIdIncrementer를 자동 적용하지 않는다. 밀리초 해상도가 충분하지 않은 환경이나 CI 노드에서 두 호출이 같은 값을 반환하면 두 번째 실행은 동일 JobInstance로 인식되어 JobInstanceAlreadyCompleteException 혹은 파라미터 검증 단계 이전에 튕기며 멱등성 검증 자체가 수행되지 않는다. 운영 관점에서 CI 플래키는 회귀 검출을 지연시키므로 유니크 파라미터를 명시적으로 부여하는 것이 안전하다.

♻️ 제안 수정안

         var params1 = new JobParametersBuilder()
                 .addString(RankingBatchJobParameters.JOB_PARAM_PERIOD, "WEEKLY")
                 .addString(RankingBatchJobParameters.JOB_PARAM_PERIOD_KEY, "2026W15")
-                .addLong("run.id", System.currentTimeMillis())
+                .addLong("run.id", 1L)
                 .toJobParameters();
         var first = jobLauncherTestUtils.launchJob(params1);
         assertThat(first.getExitStatus().getExitCode()).isEqualTo(ExitStatus.COMPLETED.getExitCode());

         var afterFirst = mvProductRankWeeklyJpaRepository.findByPeriodKeyOrderByRankValueAsc("2026W15");

         var params2 = new JobParametersBuilder()
                 .addString(RankingBatchJobParameters.JOB_PARAM_PERIOD, "WEEKLY")
                 .addString(RankingBatchJobParameters.JOB_PARAM_PERIOD_KEY, "2026W15")
-                .addLong("run.id", System.currentTimeMillis())
+                .addLong("run.id", 2L)
                 .toJobParameters();

추가로, publish 실패 시 이전 스냅샷이 보존되는지를 E2E 수준에서 확인하는 테스트가 이 파일에 보이지 않는다. PR 본문에 "publish failure preserving MV" 시나리오가 테스트로 추가된다고 명시되어 있으므로, 다른 테스트 파일에 존재한다면 그쪽에서 확인하고, 없다면 본 파일에 한 건 추가할 것을 권한다.

As per coding guidelines, "통합 테스트는 격리 수준, 플래키 가능성, 테스트 데이터 준비/정리 전략을 점검한다".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@apps/commerce-batch/src/test/java/com/loopers/job/ranking/RankingBatchJobE2ETest.java`
around lines 145 - 191, The test uses identical run.id values for both launches
(via addLong("run.id", System.currentTimeMillis())) which can collide and make
the second launch be treated as the same JobInstance; update
RankingBatchJobE2ETest to supply a truly unique job parameter for each launch
(e.g., use a UUID or System.nanoTime()) when calling
jobLauncherTestUtils.launchJob (update the params1/params2 builders that call
addLong("run.id", ...)), and ensure the new unique parameter key/value is passed
so both runs execute as separate instances; additionally, if the PR claims a
"publish failure preserving MV" scenario is covered, add or verify an extra E2E
test in this class that simulates publish failure and asserts previous snapshot
preservation.

apps/commerce-api/src/main/java/com/loopers/domain/ranking/RankingQueryService.java-88-139 (1)

88-139: ⚠️ Potential issue | 🟡 Minor

limit(100) 방어 코드가 리포지토리 쿼리 부재로 필수이며, 삭제 상품 스킵 시 rank 갭 테스트를 추가해야 한다.

JPA 리포지토리의 findByPeriodKeyAndVersionOrderByRankValueAsc에 LIMIT이 명시되어 있지 않아, 라인 113의 stream().limit(100)이 유일한 방어선이다. 리포지토리 구현 변경 시 이 제한이 무시될 수 있으므로, 메서드 또는 쿼리에 @Query(... LIMIT 100) 또는 FETCH FIRST 100 ROWS ONLY 등을 추가하고 주석으로 "상위 100건 강제"임을 명시하는 것이 회귀 방지에 도움이 된다.

또한 hydrateMvRows에서 product 또는 brand가 없으면 continue로 건너뛰는데, 이 경우 응답 배열의 rank이 비연속적이 된다(예: 1, 3, 5, ...). 현재 테스트는 모든 상품이 정상 hydrate되는 happy path만 다루고 있다. 삭제되거나 브랜드가 없는 상품이 포함된 케이스(예: 2위 상품이 deleted 상태, 또는 4위 상품의 브랜드가 없음)에 대해 응답 rank 시퀀스를 검증하는 단위 테스트 두 건을 추가하여 운영 중 갭 변화를 감지할 수 있도록 한다.